fix(core): detect template entries structurally - #7249

What

isTemplateEntry now recognises a template entry by structure instead of by the first bytes of the file. A scene file is a template entry when it has a <template> whose content holds the [data-composition-id] root and there is no live (non-template) composition root outside the template.

Why

A sub-composition file is just as often written as a complete HTML document with the <template> inside <body> (a valid page a browser or an editor can open on its own), not only as a fragment that starts with <template>:

<!doctype html>
<html>
  <head>...</head>
  <body>
    <template>
      <style>#root { ... }</style>
      <div id="root" data-composition-id="scene" data-width="640" data-height="360">...</div>
      <script>/* gsap timeline registered on window.__timelines */</script>
    </template>
  </body>
</html>

The predicate only accepted files that start with <template (after comments and whitespace), so this shape was not recognised. resolveEntryHtmlPath (the standalone-entry extraction from #7217, used by the in-process renderer) then compiled the raw file. Everything sits in an inert template, so the page has no root, no timeline and no data-duration, and rendering that scene on its own fails with Composition has zero duration. htmlBundler calls the same predicate and had the same blind spot.

Related work

Follows #7217.

How

• locateSceneRoot (new, packages/core/src/compiler/htmlDocument.ts) parses once and reports the composition root, whether a <template> exists, and whether a live root exists outside it. readSceneRoot (used for extraction) now reads its root from this same lookup, so detection and extraction agree.
• isTemplateEntry = template present, root inside it, no live root outside it. The regex prefix check is gone; leading comments and whitespace no longer matter because the HTML parser handles them.
• Several templates (review fix, Miguel): locateSceneRoot scans every <template> and takes the one whose content holds a [data-composition-id] root. If more than one template holds a root and the file has no live root, it throws: This file has more than one scene template, so it is unclear which one to render: template #1 (id="intro") holding composition "scene"; template #2 holding composition "later". Keep one composition root per file. Callers (isTemplateEntry, extractStandaloneEntryFromIndex, so resolveEntryHtmlPath and bundleProject) do not catch it, so the message surfaces instead of "Composition has zero duration". A file with a live root stays a plain entry and is never refused.
• Behaviour that does not change: template-first fragments holding a root are still template entries; a full document with a live root is still a plain entry; non-template documents are untouched; extractStandaloneEntryFromIndex output is unchanged.
• Behaviour that does change, deliberately: a <template> holding no composition root at all (for example <template></template>) is no longer a template entry, since there is nothing to extract. Such an entry now compiles as a plain file instead of being wrapped. The existing fragment test fixtures that used empty templates now carry a root.

Callers audited (git grep isTemplateEntry):

• packages/producer/src/services/render/stages/compileStage.ts resolveEntryHtmlPath: now extracts the canonical full-document shape; fragments and live-root documents behave as before.

• packages/core/src/compiler/htmlBundler.ts readMountedSceneShell: same predicate, same result change as above (canonical shape now bundled inside the mounting index).

• packages/core/src/compiler/standaloneEntry.ts and packages/core/src/compiler/index.ts: re-exports of the same function, signature unchanged ((html: string) => boolean).

• Tests: standaloneEntry.test.ts.

• Size budget: @hyperframes/inspector bundles core, and the scene lookup change grew its unpacked size just past the 1% tolerance (3681896 bytes against 3645432 at the first measurement, before the refusal code). Budget goes from 3645432 to 3650000, about 4.5 KB: what the lookup and refusal code need plus a small margin. Miguel can veto.

Test plan

Added to standaloneEntry.test.ts (predicate) and compileStage.test.ts (resolveEntryHtmlPath), using fixtures written for this PR (3 s scene, 640x360, solid background, one text element, GSAP timeline):

• the canonical full-document shape is a template entry and resolveEntryHtmlPath extracts it from an index.html that mounts it through data-composition-src; the wrapper carries the scene's own data-duration="3", not the master's
• the template-first fragment control still passes
• a scene template after earlier non-scene templates resolves the scene root (3 shapes: fragment, full document, three templates); two templates that both hold a root are refused with the message above, and a live root keeps the file a plain entry; no root in any template reports root: null; single template and template-free document unchanged
• a full document with a live composition root outside the template stays a plain entry (also the fragment-plus-live-root variant)

Run locally (changed files only):

• cd packages/core && npx vitest run src/compiler/standaloneEntry.test.ts src/compiler/htmlBundler.test.ts : 2 files, 237 tests passed
• cd packages/producer && npx vitest run src/services/render/stages/compileStage.test.ts : 1 file, 23 tests passed
• npx oxfmt --check and npx oxlint on the 4 changed files: clean; tsc --noEmit in packages/core: clean; pre-commit hooks (lefthook: lint, format, fallow, typecheck, commitlint) passed

Not exercised locally: a real browser render of a canonical-shape scene; the full repo suite and the comment ratchet scripts (they need a newer git than the local one; left to CI).

• Unit tests added/updated
• Manual testing performed
• Documentation updated (if applicable)
• Comments follow CONTRIBUTING.md "Comments"

— Jerrai